【レポート】Architecting for the Cloud 2019 – クラウドにおけるアーキテクチャの設計原則 #AWSSummit

概要

AWSを使ってセキュアで、信頼性が高く、高性能で、コスト効率の高いシステムを設計するには、どうしたらよいでしょうか？

本セッションでは、AWS のメリットを活かした、クラウドらしいアーキテクチャを構築するための原則をご紹介します。伸縮自在性に代表されるクラウドコンピューティングならではの動的な性質を活かすための考え方を学び、AWS らしい設計を行うために意識すべきベストプラクティスについてご紹介します。

• クラウドにおけるアーキテクチャの設計原則をあらためて見直す (そして 議論できるようにする)
• Webアプリにおける実践を通じて、この原則を理解する

スピーカー

レポート

基本中の基本

Amazon EC2

• 設定済みの VM
• VM 動作中 / 停止中 - 動作させた VM は いつでも停止させることができる
• EBS Snapshots (S3) - いつでも S3 にスナップショットを作成可能, スナップショットで AZ 間を移動

Amazon VPC

• 論理的に分離された環境で ネットワークを構築
• VPC Endpoints - AWS サービスへのプライベートでセキュアな接続
• Shared VPC では VPC環境を複数のアカウントで共用可能 - ネットワーク管理者 と アプリ開発者 が別の場合などに活用

AWS Global Infrastructure

• 21 geographic regions
• 61 Availability Zones
• 99.99% の可用性SLA

Architecting for the Cloud 2019

障害を見越した設計

• 冗長化
• 障害の検出 (止まっても 〇〇時間で復旧します)
• 永続データストレージ (自分のデータが失われていないか)
• 複数データセンタを用いた自動復旧 (AZをうまく使う)

全レイヤでのセキュリティ実装

• 徹底的な防御 (できるところを徹底的に)
• AWS のセキュリティサービスを積極的に使用 (使えるものは使う)
• 特権アクセス制限 (ルートアカウントではなく必要な権限を使う)
• リアルタイム監査 (可能な限りリアルタイムを目指す)

ストレージの選択肢活用

• S3
• EBS
• Glacier
• Elastic File System
• Aurora
• DynamoDB
• ElastiCache

伸縮性の実現

• ブートストラッピング or Golden Image
• ユーザーデータで ブートストラッピングできれば いつでも最新の AMI を利用可能
• Golden Image を作る場合は 伸縮できるように作成する
• 家畜として扱う (1つ1つに手間をかけて育てるペットではなく 家畜として育てる)
• 替えが効くサービス
• サービス継続性の重視
• 1つ 1つ の EC2 が落ちてもサービスに影響がないように

並列で考える

• 1台で100時間 ＝ 100台で1時間 で終わるのでは？ という考え方
• なめらかなスケーリング
• 障害影響範囲を小さく
• ソフトウェアの書き換え (ソフトウェアの制限を解消する)

疎結合はあなたを楽にします

• よいインターフェース定義
• サービス拡張
• 対応できない時の非同期処理 (SQS を使うだけでも疎結合が楽になる)
• 失敗時の適切な処理 (失敗したら SQS にもう一度入れなおす, DynamoDB に今の状態を書いておく でも OK)

制約を恐れない

• 制限には理由がある (EC2 の起動制限 など)
• 提供できるものを計画する (100% を目指すといつになるか分からない)
• うまくいくものを出荷する
• できるときに出荷する
• 繰り返し繰り返す

実践 (Web アプリ編)

• セキュリティは常に最優先

必須：アカウント要不要と権限管理、証跡

• Production アカウントについては少なくとも次の 3 つを実施

1. IAM ユーザー／グループの設定 (アカウントを共用しない)
2. CloudTrail, Config, GuardDuty, Security Hub, MFA の有効化 (非常に安価)
3. Enabling and Disabling Regions (使わないリージョンは 使わなくする, 香港リージョンから 使用時は Enable にする必要がある)

• AWS Controll Tower というランディングページを準備中。
• https://aws.amazon.com/solutions/aws-landing-zone/

AWS 上の基本的な構成

• (Public Subnet) ALB ＋ (Private) Subnet EC2 / S3 Backet

セッション情報は外に出す

• スケールさせやすくするためにセッション情報は外だし (まだまだできていない環境が多い)
• 書き換えられても問題ない情報、肥大化の恐れがない情報は Client-Side

AWS のサービスを活用した非同期処理の例

• SQS を挟んで Frontend と Backend を疎結合に

計算資源を使い捨てるために

• ブートストラッピング
  • Cloud-init を使用したソフトウェアインストール、各種設定
• ゴールデンイメージ
  • 特定の状態でスナップショットを取得
• コンテナ
  • ECS の Docker サポート
  • 必ずしも コンテナ化がゴールではなく SQS, セッション外だしだけで済む場合もある

AWS 上の基本的な構成と防御

オリジンへの外部からのアクセス禁止

• S3 Origin Access Identity
• S3 バケットへの直接アクセス防止
• 直接アクセス可能な S3 URL 廃止
• Custom Origin Security Groups
• CloudFront の IP レンジのホワイトリスト

今日の Web アプリに対する最大の脅威

• DDoS
• App Vulnerabilities
• Bad Bots

CloudFront による防御レイヤ追加

• CloudFront を入れておけば WAF の導入が容易
• 複数アカウントを束ねるために Firewall Manager を提供

DDoS 対策用の防御レイヤ追加

• AWS を使うだけで L4 レベルの攻撃を防御可能
• それ以上の防御は Shield Advanced

まとめ

• 障害を見越した設計
• 全レイヤでのセキュリティ実装
• ストレージ選択肢活用
• 伸縮性の実現
• 並列で考える
• 疎結合はあなたを楽にします
• 制約を恐れない

AWS Well-Architected Tool を見る ことを設計原則に取り入れる

• セルフサービスで Well-Architected Framework を活用できる
• 活用が難しいお客様には Trusted Advisor (ビジネスサポート契約で 全機能を利用可能)

参考資料 (ホワイトペーパー)

• Architecturing for The Cloud : AWS Best Practices
• AWS Well-Architected フレームワーク

感想